fix(i18n): the percent sign closes to hanzi, like a unit (TASK-180 %-gate) - #1988

… rule-32 link to a neighbour note

From the gate's answer on whether 43 is a rider on 32. It is a separate rule, and
the reason is rule 41's own test applied to 32: every guard 32 sends you to check
passes on #1988 — the head is fetchable, it never moved, and there is no merge to
compare a clearance against — and the defect survives all of them. 32 asks an
identity question, which presupposes a gate; 43 asks an existence question and
sits upstream of that family.

So the body now leads with the question 32 cannot ask and the 32 link is a
neighbour note at the end, the way 41 handles 24. That ordering is the whole
fix: the rule said the right thing in the order that made it read as a
restatement of 32. Nothing operative changed.

Kept, and named as the half 32 cannot reach: a sha resolving in the author's
clone and nowhere else reads as sound to its author and as absent to every other
seat. Neither side can see that asymmetry alone — which is why the incident
needed both seats to close, and why the rule names the asymmetry rather than
just the symptom.

Removed from the earned clause: the discriminating checks, now stated in the
body, so they appear once.

Guard, CI's own invocation, --previous = a20ea9b:
  ✓ 43 rules, numbers 1..43 ascending with no gap, 21 citation(s) all resolve,
    and no rule changed its number or its name.

… (a clearance binds a head the consumer can resolve)

Two rules, both earned today, appended at EOF under their own headings.
Rule 42 was drafted 2026-09-28 and held while #1994 claimed rule 41; that PR
merged at 12:59:44Z as a20ea9b, so this is the first cycle in which the
numbers were free.

42 — a queued PR refuses every push (GH006), and that refusal is what keeps
the pressed head equal to the gated head. Incident: #1984 was queued 95s
after the % fold was asked for, so the fold became #1988 — a one-line catalog
change billed as a PR with a rebase and two gates. The rule records that the
queue merged the gated head faithfully and that the refusal is the mechanism
holding rule 32's tree comparison true, not an obstacle.

43 — a clearance binds a head the consumer can resolve, and prose is not a
head. Incident: TASK-186 carried "CODE PASS @ 1a811d8" in its board title for
~32h while #1988's PR held no code clearance at all; the pod line behind the
claim named 5829815, a local commit the merge queue never let push, so the
sha was resolvable in one clone and nowhere else.

Verified through the numbering guard's own CI invocation (script extracted
from origin/main, run from the repo root, --previous = the main this is based
on):

  ✓ 43 rules, numbers 1..43 ascending with no gap, 21 citation(s) all
    resolve, and no rule changed its number or its name.

Docs only: one file, +8 lines, no code and no tests. The guard is the test.

… rule-32 link to a neighbour note

From the gate's answer on whether 43 is a rider on 32. It is a separate rule, and
the reason is rule 41's own test applied to 32: every guard 32 sends you to check
passes on #1988 — the head is fetchable, it never moved, and there is no merge to
compare a clearance against — and the defect survives all of them. 32 asks an
identity question, which presupposes a gate; 43 asks an existence question and
sits upstream of that family.

So the body now leads with the question 32 cannot ask and the 32 link is a
neighbour note at the end, the way 41 handles 24. That ordering is the whole
fix: the rule said the right thing in the order that made it read as a
restatement of 32. Nothing operative changed.

Kept, and named as the half 32 cannot reach: a sha resolving in the author's
clone and nowhere else reads as sound to its author and as absent to every other
seat. Neither side can see that asymmetry alone — which is why the incident
needed both seats to close, and why the rule names the asymmetry rather than
just the symptom.

Removed from the earned clause: the discriminating checks, now stated in the
body, so they appear once.

Guard, CI's own invocation, --previous = a20ea9b:
  ✓ 43 rules, numbers 1..43 ascending with no gap, 21 citation(s) all resolve,
    and no rule changed its number or its name.

…cient — a review at the head can be a refusal

ux-lead's re-gate, and the gap is the one my own ask left open. Their CHANGES @ d1d56e4
was itself the counterexample: that head's ONLY review was a refusal, so "a review
exists whose commit_id is the pressed head" cleared a head that had just been refused.

Measured before folding:
  #1988 reviews=4   states=COMMENTED
  #1989 reviews=10  states=COMMENTED
  #2000 reviews=4   states=COMMENTED
All 18 reviews COMMENTED; not one APPROVED or CHANGES_REQUESTED. So `state` carries
no verdict in this workflow and the verdict is the body's first line and nothing else.
That is why the check has to be per required gate, against the first line, rather
than against the presence of a review object.

Rule 43 now says: a clearance has to exist as a PASS recorded against the head being
pressed; existence is necessary and not sufficient; a head whose reviews are all
refusals or all corrections ("Correction to my gate above" declares no verdict) is
ungated.

Guard, CI's invocation, --previous = 87c7325:
  ✓ 43 rules, numbers 1..43 ascending with no gap, 23 citation(s) all resolve,
    and no rule changed its number or its name.

…-moved witnesses (TASK-190)

sprint-review's re-gate finding, reproduced and it holds. Rule 32 claimed tree
equality fails on #1994 for a SECOND reason: "squash-shaped only: a20ea9b is a
two-parent merge-queue commit whose ^{tree} is main's tree rather than the
head's, so the comparison cannot be run there at all". Measured:

  git rev-list --parents -n 1 a20ea9b  ->  one parent (95356c5)

So it is not a merge of any shape. And with the base taken as the merge base,
the patch-id agrees on both sides exactly like the other three:

  95356c5..a20ea9b  391ca7f451da
  4e39c99..b2da9bf  391ca7f451da

Trees for the record: parent 0de9aac, landed commit 3a24f1a, carried head
683663d — a base move, the same cause as #1988/#1989/#1992.

The clause is deleted rather than patched, and #1994 joins the other three as a
fourth witness: one cause with four measurements beats two causes where one is
refuted by `rev-list`. On the shape claim itself, measured over main: all 200 of
its most recent commits have exactly one parent, and the newest two-parent
commit is dc9d849 (2026-04-07, 1766 commits back), so "the merge queue's shape"
describes something this repo stopped producing in April.

The rule's earned text now carries the correction, because the false claim was
published in the rule that exists to catch names and tests that do not measure
what they say they measure.

Guard, both modes: 44 rules, numbers 1..44 ascending with no gap, 28 citations
all resolve, no rule changed its number or its name.

Written by sprint-review, a Commonly agent.
Pod thread: https://commonly.me/v2/pods/6a692a1be833c668acdb84cf (message 76014)

All five applied with ux-lead's literal text; the two testable ones were
reproduced here first.

1. "every mutation" was false. Arm C, `Math.max(2, …)` on arm B's fixture:
   2 failed / 1 passed / 3 total (BASE and RESTORED 3/3). The equal-only
   fixture greens mutations that ERASE the difference, not every mutation
   of the line.
2. The clamp came in with `d331c11ea` (created localizeRelativeTime.ts,
   +106, diff contains the clamp), not `79f5cb48d` (+51, test file only).
   `git log -S` over the clamp string on main returns #1981's squash; within
   the branch it is d331c11. 79f5cb4 is the pin and carries the 1ms
   measurement, and is now cited as that.
3. The #1982 figure regained its head, `faf43bb2` — dropped when I applied
   ux-lead's earlier text.
4. The zh gloss inverted its source: the author's own account says
   `None == None` read as "untranslated in zh", not "already translated".
5. "Eight rows agreed with both readings" was wrong. On my own table only
   three do (#2015, #2046, #2048); the other five agree with the title
   reading alone. Corrected, and the 60-squash anchor now names its window
   (#1988-#2053 up to faf43bb).

Numbering guard green: 50 rules, 1..50, 52 citations resolve, no lead moved.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…ange (TASK-181)

Written by sprint-review, a Commonly agent.
Pod thread: https://commonly.me/v2/pods/6a692a1be833c668acdb84cf (message 76019)

ux-lead's non-blocking note on their own part 5, verified before applying.
My sample was `git log --no-merges -60` — 60 first-parent squash positions
on main. Describing it as "#1988-#2053" restated a positional count as a
numeric range, and that range holds 66 merged PRs: the six extras (#1990,
#1991, #1993, #1994, #1996, #1997) are each absent from the 60 and sit at
first-parent positions 61-69, confirmed per PR.

Reworded positionally rather than patching 60 to 66, because the sample was
never a number range and a re-run drifts: the same command today spans
#1988-#2054, #2054 having merged after faf43bb. "60 consecutive squash
commits ending at faf43bb" is re-derivable; a number range is not the thing
that was measured.

The 8 of 8 is the same eight PRs on either set, so no figure moves.

Numbering guard green: 50 rules, 1..50, 52 citations resolve, no lead moved.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

… (a clearance binds a head the consumer can resolve) (Team-Commonly#2000)

* docs(checklist): rule 42 (a queued PR refuses every push) and rule 43 (a clearance binds a head the consumer can resolve)

Two rules, both earned today, appended at EOF under their own headings.
Rule 42 was drafted 2026-09-28 and held while Team-Commonly#1994 claimed rule 41; that PR
merged at 12:59:44Z as a20ea9b, so this is the first cycle in which the
numbers were free.

42 — a queued PR refuses every push (GH006), and that refusal is what keeps
the pressed head equal to the gated head. Incident: Team-Commonly#1984 was queued 95s
after the % fold was asked for, so the fold became Team-Commonly#1988 — a one-line catalog
change billed as a PR with a rebase and two gates. The rule records that the
queue merged the gated head faithfully and that the refusal is the mechanism
holding rule 32's tree comparison true, not an obstacle.

43 — a clearance binds a head the consumer can resolve, and prose is not a
head. Incident: TASK-186 carried "CODE PASS @ 1a811d8" in its board title for
~32h while Team-Commonly#1988's PR held no code clearance at all; the pod line behind the
claim named 5829815, a local commit the merge queue never let push, so the
sha was resolvable in one clone and nowhere else.

Verified through the numbering guard's own CI invocation (script extracted
from origin/main, run from the repo root, --previous = the main this is based
on):

  ✓ 43 rules, numbers 1..43 ascending with no gap, 21 citation(s) all
    resolve, and no rule changed its number or its name.

Docs only: one file, +8 lines, no code and no tests. The guard is the test.

* docs(checklist): fix both earned clauses against the ledger (rule 43's sha and spans, rule 42's file count)

Sprint-review's CHANGES gate on b1515f5, all three findings confirmed by
measurement rather than accepted on report. Two of the three were in the
earned clauses, which is the worst place for them: the evidence IS the rule.

Rule 43 named the wrong sha. The row recorded "CODE PASS @ 5829815" — the
local-only commit, which is the whole point — at 06:54Z on 2026-09-28; the
rule said 1a811d8, which is the head the row got RIGHT and which carried only
the UX pass until a real code gate landed at 12:17:58Z. As written the example
could not demonstrate its own rule: 1a811d8 is resolvable, so nothing about it
is ungated.

The spans were also wrong. Measured from the ledger: the row carried the claim
29.4h (06:54:19.520Z -> 12:17:58.983Z), the board title 8.7h (03:34:40.553Z ->
12:17:58.983Z, the 20.7h gap being the lag between the row and the title). The
"~32h" matched neither.

Added, because it is the mechanism the wrong sha came from: the title read
"(UX PASS @ 1a811d8 + CODE PASS)" — it binds the sha to the UX pass and leaves
the code pass bare, which is exactly how a reader collapses it into "CODE PASS
@ 1a811d8". The wrong sha was not carelessness, it was the title's shape, and
that shape is a second defect in the same title worth naming.

Rule 42's "exactly one tracked file" was true of main and false at this head:
b1515f5:.github/workflows/tests.yml plus b1515f5:docs/development/
review-checklist.md, because the rule quotes GH006 / "queued for merging" /
"merge queue". Scoped to "before this entry existed", with the head-count
stated so the next reader running git grep -l does not read two as a defect.
Measured per string: GH006 and "queued for merging" appear only in this file at
this head; "merge queue" is in both.

Not changed: "95 seconds later". The two printed stamps (04:48:45Z, 04:50:20Z)
differ by 95s as displayed; sprint-review's 94.3s is the same gap at
sub-second precision, which the rule does not print.

Guard, CI's own invocation, --previous = a20ea9b:
  ✓ 43 rules, numbers 1..43 ascending with no gap, 21 citation(s) all resolve,
    and no rule changed its number or its name.

* docs(checklist): lead rule 43 with the existence question, demote the rule-32 link to a neighbour note

From the gate's answer on whether 43 is a rider on 32. It is a separate rule, and
the reason is rule 41's own test applied to 32: every guard 32 sends you to check
passes on Team-Commonly#1988 — the head is fetchable, it never moved, and there is no merge to
compare a clearance against — and the defect survives all of them. 32 asks an
identity question, which presupposes a gate; 43 asks an existence question and
sits upstream of that family.

So the body now leads with the question 32 cannot ask and the 32 link is a
neighbour note at the end, the way 41 handles 24. That ordering is the whole
fix: the rule said the right thing in the order that made it read as a
restatement of 32. Nothing operative changed.

Kept, and named as the half 32 cannot reach: a sha resolving in the author's
clone and nowhere else reads as sound to its author and as absent to every other
seat. Neither side can see that asymmetry alone — which is why the incident
needed both seats to close, and why the rule names the asymmetry rather than
just the symptom.

Removed from the earned clause: the discriminating checks, now stated in the
body, so they appear once.

Guard, CI's own invocation, --previous = a20ea9b:
  ✓ 43 rules, numbers 1..43 ascending with no gap, 21 citation(s) all resolve,
    and no rule changed its number or its name.

* docs(checklist): rule 42's file count is per string, not per union; rebase onto 87c7325

The gate's non-blocking finding, folded because the entry is being touched anyway:
"exactly one tracked file" is true of the union and false per string. Measured over
the whole tree on main (no pathspec), `git grep -l -F` returns:
  GH006 -> 0 files · queued for merging -> 0 files · merge queue -> 1 file
The one hit is .github/workflows/tests.yml:13, and lines 13-16 are about the
merge_group trigger. So a reader grepping GH006 alone gets nothing and can read
the rule as stale — which is the failure the sentence was written to prevent.

Also rebased onto 87c7325 (main moved; Team-Commonly#1995, disjoint — it does not touch this
file). Text is otherwise unchanged from 9a8ec6e.

Guard, CI's own invocation, --previous = 87c7325:
  ✓ 43 rules, numbers 1..43 ascending with no gap, 21 citation(s) all resolve,
    and no rule changed its number or its name.

* docs(checklist): cut rule 43 down to existence — the sha was on the remote all along

ux-lead's second seat on the conclusion, and the finding is against my own rule's
premise. Verified independently in a fresh clone before taking it:

  gh api repos/.../commits/58298156        -> resolves, parent 7f17163
  git fetch origin 5829815...       -> retrieves it
  git fetch origin 5829815                -> couldn't find remote ref
  advertised refs pointing at it           -> 0 of 2,579
  merge-base --is-ancestor 5829815 1a811d8 -> NOT an ancestor (a sibling)
  /pulls/1988/reviews                      -> 4 reviews, all commit_id=1a811d84

So "a local commit GH006 never let push" was false: the remote had it the whole
time and a full-sha fetch gets it. What was missing was not resolvability but a
gate — no review was ever taken at that head. Rule 43 now asks the existence
question and nothing else; "absent from the reader's clone" is dropped as the
test (an absence read in one clone is as clone-local as a presence read, and
refs/pull/<n>/head keeps a squashed-away head fetchable), the instrument is
commit_id, and --is-ancestor is named as a check that passes a spent stamp.

Rule 42, both non-blocking asks folded: the follow-up PR is ungated until gated
at its own head and the pre-rebase commit is provenance cited by full sha; the
refusal keeps the merged head equal to the queued head, not to the gated one.

Guard, CI's invocation, --previous = 87c7325:
  ✓ 43 rules, numbers 1..43 ascending with no gap, 23 citation(s) all resolve,
    and no rule changed its number or its name.

* docs(checklist): rule 43's existence check is necessary and not sufficient — a review at the head can be a refusal

ux-lead's re-gate, and the gap is the one my own ask left open. Their CHANGES @ d1d56e4
was itself the counterexample: that head's ONLY review was a refusal, so "a review
exists whose commit_id is the pressed head" cleared a head that had just been refused.

Measured before folding:
  Team-Commonly#1988 reviews=4   states=COMMENTED
  Team-Commonly#1989 reviews=10  states=COMMENTED
  Team-Commonly#2000 reviews=4   states=COMMENTED
All 18 reviews COMMENTED; not one APPROVED or CHANGES_REQUESTED. So `state` carries
no verdict in this workflow and the verdict is the body's first line and nothing else.
That is why the check has to be per required gate, against the first line, rather
than against the presence of a review object.

Rule 43 now says: a clearance has to exist as a PASS recorded against the head being
pressed; existence is necessary and not sufficient; a head whose reviews are all
refusals or all corrections ("Correction to my gate above" declares no verdict) is
ungated.

Guard, CI's invocation, --previous = 87c7325:
  ✓ 43 rules, numbers 1..43 ascending with no gap, 23 citation(s) all resolve,
    and no rule changed its number or its name.

* docs(checklist): rule 43's review counts are dated, not live — a count in a doc decays

* docs(checklist): rule 43's per-gate check must name the head, not just carry its commit_id

* docs(checklist): fold rule 43's re-gate — candidates not clearances, and the differing-tree witness

---------

Co-authored-by: lilyshen0722 <lilyshen0722@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

…ork point is measured (TASK-190) (Team-Commonly#2013)

* docs(checklist): rule 32's fidelity test is patch-id, and rule 44's fork point is measured (TASK-190)

Four corrections carried out of the Team-Commonly#2000 landing, each a defect in text now on
main rather than in an open branch.

1. RULE 44, a false statement of fact. The earned clause called `58298156` "a
   sibling of `1a811d84`". Measured on the real commits:
   `git merge-base 5829815 1a811d8` = `bbab5c31`, and
   `git merge-base 7f17163 1a811d8` = the same commit — so `7f171637` is no
   ancestor of `1a811d84` either, and the two heads are separate takes on the
   same TASK-180 change. The sentence now says "diverge at `bbab5c31`".

2. RULE 32, a wrong instrument. Its headline and its proof sentence compared
   `rev-parse <merge>^{tree}` against `<head>^{tree}`. Both failures were
   measured: it is BASE-RELATIVE (any base move under the PR makes the trees
   differ necessarily while the landing is faithful — Team-Commonly#1988/Team-Commonly#1989/Team-Commonly#1992 all
   landed faithfully with differing trees) and SQUASH-SHAPED ONLY (`a20ea9b3`,
   Team-Commonly#1994's landing, is a two-parent merge-queue commit whose `^{tree}` is
   main's tree, so the comparison cannot be run there at all). The test is now
   patch-id of `<merge>^..<merge>` against `<base>..<head>`, which is what held
   for all three of those landings (`81ecc062`, `b9feb00c`, `efcec768`) and is
   the instrument the AX audit reached independently for a refresh carry
   (entry 65).

3. THE REHEARSAL RIDER on rule 32: a guard arm, mutation run or probe binds to
   a head exactly as a clearance does. On Team-Commonly#1994's hold, three arms were quoted
   after a third head move, and ARM 1 had measured a file that no longer existed
   at the then-current head.

4. THE RENUMBER CLAUSE in rule 43: its own squash subject announces "rule 42
   … and rule 43" while the file it landed carries those as 43 and 44, because
   Team-Commonly#2008 merged its own rule 42 between the gate and the press. A rule number is
   a queue position; a reader citing the log gets both wrong.

TWO RECONCILIATIONS the instrument change required, beyond the row's scope and
deliberately in the same diff: rule 32's earned text and rule 43's body both
still asserted "the tree comparison", which the new headline contradicts. An
internal contradiction is worse than either sentence alone, and the change of
instrument is what made them false.

Guard: `node scripts/verify-numbered-rules.js` -> 44 rules, numbers 1..44
ascending with no gap, 28 citations all resolve. Docs only; no other file in the
tree quotes rule 32's tree test or its headline (checked by grep).

* docs(checklist): correct rule 32's test in the body, not in its lead (TASK-190)

The guard caught this, and it was right to. `node scripts/verify-numbered-rules.js`
without `--previous` is the weaker check — CI runs it with `--previous <main>`,
and that mode pins every rule's LEAD sentence as its name: a rewritten lead is
byte-indistinguishable from a foreign rule claiming the same number, so the job
failed with

  rule 32 on main is "Verify a merge at the consumer: for a squash merge, the
  merg…" and this version's rule 32 is "Verify a merge at the consumer: the
  change that landed must …" (line 105) — one number, two rules.

The script documents that as deliberate and without bypass, and its reason is
sound: ADR-028, ADR-019, REVIEW.md and nine citations inside the file refer to
rules by NUMBER, and the lead is how a reader verifies the citation landed on
the right text. So the correction moves to the body, where the script's own
docstring says in-place edits belong.

Rule 32 now keeps main's lead verbatim and opens its body by scoping it: the
tree equality in the lead is the SPECIAL CASE, not the test — it holds only
while the base has not moved under the pull request — with the general test
being patch-id of the merge's own range against the gated range. The lead is
therefore not left asserting a general rule it does not hold as.

That leaves a real gap, filed as TASK-198 rather than papered over: a rule whose
lead is ITSELF false has no in-place repair under this guard, only (a) scope the
falsehood in the body as done here, or (b) delete and re-append, which renumbers
every rule after it and re-points every citation. The proposed mechanism is a
declared amendment — the body naming the lead it replaces — which keeps the
property the guard actually wants, namely telling "same rule, retitled" from
"foreign rule at this number".

Everything else from the previous head stands: rule 44's fork point measured as
bbab5c3, the rehearsal rider, the renumber clause, and the two sentences that
had to stop saying "the tree comparison".

Guard, both modes: 44 rules, numbers 1..44 ascending with no gap, 28 citations
all resolve, and no rule changed its number or its name.

* docs(checklist): rule 32's second failure cause was false — four base-moved witnesses (TASK-190)

sprint-review's re-gate finding, reproduced and it holds. Rule 32 claimed tree
equality fails on Team-Commonly#1994 for a SECOND reason: "squash-shaped only: a20ea9b is a
two-parent merge-queue commit whose ^{tree} is main's tree rather than the
head's, so the comparison cannot be run there at all". Measured:

  git rev-list --parents -n 1 a20ea9b  ->  one parent (95356c5)

So it is not a merge of any shape. And with the base taken as the merge base,
the patch-id agrees on both sides exactly like the other three:

  95356c5..a20ea9b  391ca7f451da
  4e39c99..b2da9bf  391ca7f451da

Trees for the record: parent 0de9aac, landed commit 3a24f1a, carried head
683663d — a base move, the same cause as Team-Commonly#1988/Team-Commonly#1989/Team-Commonly#1992.

The clause is deleted rather than patched, and Team-Commonly#1994 joins the other three as a
fourth witness: one cause with four measurements beats two causes where one is
refuted by `rev-list`. On the shape claim itself, measured over main: all 200 of
its most recent commits have exactly one parent, and the newest two-parent
commit is dc9d849 (2026-04-07, 1766 commits back), so "the merge queue's shape"
describes something this repo stopped producing in April.

The rule's earned text now carries the correction, because the false claim was
published in the rule that exists to catch names and tests that do not measure
what they say they measure.

Guard, both modes: 44 rules, numbers 1..44 ascending with no gap, 28 citations
all resolve, no rule changed its number or its name.

* docs(checklist): the 60-character name pin is a window, not a wall (TASK-190)

sprint-review measured that fingerprint() ends .slice(0, 60), so the guard
binds only the first 60 characters of a rule's lead — and rule 32's claim
that such a correction has no in-place mechanism was therefore false.

Reproduced with a paired control on the real script: editing rule 32's lead
from character 61 stays green (44 rules, no rule changed its name, exit 0);
editing it at character 3 reds with the collision error. 40 of the file's 44
leads exceed 60 characters; 2,948 characters of lead text sit outside the pin.

States the boundary and rescopes TASK-198 to the question it actually raises.

* docs(checklist): name the base, and say what the two heads actually were (TASK-190)

Two findings from sprint-review's gate, both open in the text rather than
refuted by it.

(b) rule 32 prescribed the patch-id proof without naming the base, and the
only guidance for it sat three sentences away framed around a different trap.
The base is now named where the proof is prescribed:
BASE=$(git merge-base <carried-head> <merge>), the value actually run on all
four of today's landings.

(a) rule 44 called 5829815 and 1a811d8 'separate takes on the same change'.
They are stronger than that: both single-commit diffs return patch-id
81ecc06228fb, the patch-id the landing itself was verified by — the same
change on two bases, which is precisely why the stale stamp was seductive.

* docs(checklist): the pin counts normalised characters, so name the raw offset (TASK-190)

sprint-review's non-blocking addition, folded while the stamp is unspent rather
than deferred: fingerprint() strips ** and `*_ and collapses whitespace BEFORE
it slices, so the 60 are counted on the normalised lead and the boundary lands
at a different raw offset in every lead carrying markup.

Measured: rule 35's pin ends at raw character 64, rule 41's at 62, rule 13's at
61. Counting raw lengths gives 2,978 where the pin's own measure gives 2,948 --
the re-derivation error this sentence closes.

* docs(checklist): the pin can skip over 60 — rule 41's raw offset does not exist

Reviewer's finding: the sentence gave rule 41's raw offset as 62, computed as
the last offset before the boundary while rules 35 and 13 were given as the
offset at which the normalised count reaches 60 — one sentence, two quantities.

Reproduced here on the file's own parseRules/fingerprint, and it is worse than
a wrong number: fingerprint() ends .trim(), so a prefix that ends on a space
has that space discounted and the next raw character makes it interior and
counted. The normalised length can therefore step 59 -> 61 straight over the
boundary, and four leads have NO raw offset that normalises to exactly 60:
rules 3, 23 and 42 (raw 60 -> 61) and rule 41 (raw 62 -> 63). Exact landings:
34 leads at 60, rule 13 at 61, rule 35 at 64.

Guard, CI's mode: 44 rules, 1..44, 38 citations resolve, no rule changed its
number or its name.

* docs(checklist): state the pin's raw offsets as a set, and the renumber clause's real cause

ux-lead's docs gate on the previous head measured three false sentences.

The pin does not land *between* two raw offsets in rules 3, 23, 41 and 42 —
it lands on one: mutating a character either side of the boundary shows the
pin ending at raw 60 in 37 of the 40 long leads, at 61 in rule 13, at 62 in
rule 41 and at 64 in rule 35. The 59 -> 61 step is real but belongs to a
prefix-by-prefix re-derivation, where `.trim()` discounts a trailing space;
in the full lead that space is interior and counted. The sentence now gives
the four end offsets, which add to 40, and moves the step to the sentence
about re-deriving.

"every lead that carries markup" is false for rules 14, 26 and 33, whose
markup sits after the boundary and which end at raw 60 — now "every lead
whose markup sits before it".

Rule 43 attributed the 42/43 -> 43/44 discrepancy to Team-Commonly#2008 merging between
the gate and the press. It did not: Team-Commonly#2008 merged at 15:35:29Z, both clearing
gates are at `b32428b9` (15:39 and 15:41), and that head's file already reads
43 and 44. What stayed stale is the title and the first commit's subject,
which the squash composed.

Also: the two-parent commit count now names the base it was measured from
(`50a454b0`), and the collision error is cited to TASK-198 rather than to
"above", where it was never quoted.

* docs(checklist): the mutation direction was inverted, and a re-derived count is not a control

sprint-review's second gate found one sentence false: the method this
paragraph hands a reader. "An edit to the last counted character leaves it
green, and one character earlier reds it" is backwards. The pin's last
counted character is inside the pin, so editing it reds the guard, and a
character later is outside it and green. Measured on rule 41, whose pin's
last counted character is the space at raw 62: raw 61 and 62 red, 63 and 64
green. A method given with its direction inverted lands the reader one
character past the boundary it is being used to find, which is how the wrong
number got published in the first place.

The paragraph's other numbers stand and are re-measured here from the lead
text: the pin ends at raw 60 in 37 of the 40 long leads, 61 in rule 13, 62
in rule 41, 64 in rule 35, and the prefix-by-prefix steps are at raw 60->61
in rules 3, 23 and 42 and at raw 62->63 in rule 41.

Also stated, because the retraction is the more useful finding: a count
re-derived with the instrument under test is not a control. The
prefix-by-prefix re-derivation was gated twice and passed, confirming the
error rather than the boundary. The arm that refutes a boundary claim is the
mutation in the direction the claim asserts, and the check on a
re-derivation is a differently-derived number.

…things are equal (TASK-181) (Team-Commonly#2055)

* docs(review): rule 50 — a fixture supplying only the input where two things are equal (TASK-181)

Written by sprint-review, a Commonly agent.
Pod thread: https://commonly.me/v2/pods/6a692a1be833c668acdb84cf (message 75951)

Filed by sprint-impl from my own generalisation in Team-Commonly#1982's artifact loop,
with the rider-or-rule call left to me. It earns its own number: rule 41's
test asks whether every check the adjacent rule sends you to run passes
here, and for rule 17 all of them do — the fixture calls the real function
with a real catalog, so the shape is genuine and only the discriminating
value is missing.

Demonstrated rather than argued, two arms on `localizeWindow`:
  A. clamp removed, test as it stands  -> 1 failed / 3 total (line 31)
  B. same mutant, only `minutes(1)` cut -> 3 passed / 3 total, GREEN
30s is 0.5min and Math.round(0.5) === 1, so the fixture's only sub-minute
input cannot see the deletion. Totals hold at 3, so neither is a rule-46
collapse. BASE 3/3, RESTORED 3/3.

Two citations in the filed row were wrong and are corrected here: the clamp
landed in Team-Commonly#1981 (79f5cb4), not Team-Commonly#1980, and the killing case is 1ms, not
the 30s originally proposed in that gate.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* docs(review): rule 50 — the discriminating input can be present and dismissed

Written by sprint-review, a Commonly agent.
Pod thread: https://commonly.me/v2/pods/6a692a1be833c668acdb84cf (message 75959)

A second citation for rule 50, earned by its own author within the hour, and
a variant the first draft did not name: the distinguishing case was PRESENT
in the fixture and got filed as an anomaly.

Gating Team-Commonly#2054 I tested `landed == PR title + " (#N)"` across nine squashes,
got 8 of 9, and explained the ninth as a presser overwriting the subject
box. The untested rival was `landed == tip commit subject`. The repo is set
to COMMIT_OR_PR_TITLE: one commit defaults to the COMMIT's subject, 2+ to
the PR title. That column splits the nine perfectly by commit count (4/4 and
5/5), and over the last 60 squashes, where the two texts diverge on a
one-commit PR, the commit subject wins 8 of 8 and the title 0 of 8.

Eight rows agreed with both readings because their candidate strings were
identical. Team-Commonly#2031 was the only row carrying information, and I discarded it.
Caught by ux-lead, who ran the column I skipped.

Numbering guard green: 50 rules, 1..50, 52 citations resolve, no lead moved.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* docs(review): rule 50's Team-Commonly#1982 citation — one PASS, and the input caught it

Written by sprint-review, a Commonly agent.
Pod thread: https://commonly.me/v2/pods/6a692a1be833c668acdb84cf (message 75951)

@ux-lead's two corrections on Team-Commonly#2055, both verified here before applying.

1. `07873c19` carried ONE PASS, not two. Enumerated the review list: my CODE
   GATE PASS (22:38:13Z) and ux-lead's UX-GATE FAIL (22:50:18Z), both at that
   head. The two PASSes exist at the NEXT head `83408e61`, after the fix — the
   original sentence conflated the two heads.

2. "ux-lead's render caught what the suite could not" was wrong about the
   mechanism, and wrong in the direction that matters for this rule. Measured:
   BASE 22/22; reverting line 527 to the pre-fix `pod: targetLabel` gives
   1 failed / 21 passed / 22 total; RESTORED 22/22. The suite CAN see it. What
   it lacked at gate time was the seat-target grant, and the test carrying that
   input was added BY the fix (`83408e61`, +24 lines), its own comment calling
   it "the fix's own control".

That is the rule stating itself: the instrument was never blind, the fixture
had no input on which the two readings differ. Sentence replaced with the
literal text ux-lead proposed.

Numbering guard green: 50 rules, 1..50, 52 citations resolve, no lead moved.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* docs(review): rule 50 — five corrections from ux-lead's gate (TASK-181)

Written by sprint-review, a Commonly agent.
Pod thread: https://commonly.me/v2/pods/6a692a1be833c668acdb84cf (message 76014)

All five applied with ux-lead's literal text; the two testable ones were
reproduced here first.

1. "every mutation" was false. Arm C, `Math.max(2, …)` on arm B's fixture:
   2 failed / 1 passed / 3 total (BASE and RESTORED 3/3). The equal-only
   fixture greens mutations that ERASE the difference, not every mutation
   of the line.
2. The clamp came in with `d331c11ea` (created localizeRelativeTime.ts,
   +106, diff contains the clamp), not `79f5cb48d` (+51, test file only).
   `git log -S` over the clamp string on main returns Team-Commonly#1981's squash; within
   the branch it is d331c11. 79f5cb4 is the pin and carries the 1ms
   measurement, and is now cited as that.
3. The Team-Commonly#1982 figure regained its head, `faf43bb2` — dropped when I applied
   ux-lead's earlier text.
4. The zh gloss inverted its source: the author's own account says
   `None == None` read as "untranslated in zh", not "already translated".
5. "Eight rows agreed with both readings" was wrong. On my own table only
   three do (Team-Commonly#2015, Team-Commonly#2046, Team-Commonly#2048); the other five agree with the title
   reading alone. Corrected, and the 60-squash anchor now names its window
   (Team-Commonly#1988-Team-Commonly#2053 up to faf43bb).

Numbering guard green: 50 rules, 1..50, 52 citations resolve, no lead moved.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* docs(review): rule 50 — the 60 is a positional sample, not a number range (TASK-181)

Written by sprint-review, a Commonly agent.
Pod thread: https://commonly.me/v2/pods/6a692a1be833c668acdb84cf (message 76019)

ux-lead's non-blocking note on their own part 5, verified before applying.
My sample was `git log --no-merges -60` — 60 first-parent squash positions
on main. Describing it as "Team-Commonly#1988-Team-Commonly#2053" restated a positional count as a
numeric range, and that range holds 66 merged PRs: the six extras (Team-Commonly#1990,
Team-Commonly#1991, Team-Commonly#1993, Team-Commonly#1994, Team-Commonly#1996, Team-Commonly#1997) are each absent from the 60 and sit at
first-parent positions 61-69, confirmed per PR.

Reworded positionally rather than patching 60 to 66, because the sample was
never a number range and a re-run drifts: the same command today spans
Team-Commonly#1988-Team-Commonly#2054, Team-Commonly#2054 having merged after faf43bb. "60 consecutive squash
commits ending at faf43bb" is re-derivable; a number range is not the thing
that was measured.

The 8 of 8 is the same eight PRs on either set, so no figure moves.

Numbering guard green: 50 rules, 1..50, 52 citations resolve, no lead moved.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>